(19) 



J 



(12) 



Europdisches Patentamt 
European Patent Office 
Off ice europ^n des brevets (11) EP 0 982 692 A2 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

01.03.2000 Bulletin 2000/09 

(21) Application number: 99115810.6 

(22) Date of filing: 1 1 .08.1 999 



(51) lntCl7: G07F7/10, G06K 19/07, 
G06K 7/06 



(84) Designated Contracting States: 


(72) Inventors: 


AT BE CH CY DE DK ES R FR GB GR IE IT LI LU 


* Hamann, Ernst-Michael 


MGNLPTSE 


71034 Bdblingen (DE) 


Designated Extension States: 


• Schdck, Thomas 


AL LT LV MK RO SI 


77855 Achem (DE) 




• Sulzmann, Robert 


(30) Priority: 26.08.1998 DE 19838628 


71088 Holzgerilngen (DE) 


(71) Applicant: 


(74) Representative: 


International Business Machines 


Teufel, Fritz, Dipl.-Phys. 


Corporation 


IBM Deutschland Infbrmattonssysteme GmbH, 


Armonk, NY 10504 (US) 


Patentwesen und Urheberrecht 




70548 Stuttgart (DE) 



CM 
< 

CM 
O) 
(O 

CM 
CO 

o> 
o 

Q. 
LU 



Application 
1 




Appficaton 
2 




Application 
3 




Application 
4 


PKCS#11 




COSA 




CAP» 


























Comn 


on virtual sme 


rt card in 


ertaoo 







Virtual smart card ad^tei 



Smart card 
module 



I 



(54) Expanded smart card communication architecture and procedure for communicating 
between smart card application and data carrier 

(57) The present invention desaibes an improved 
communication architecture for smart card systems and 
an improved procedure for communication of the smart 
card applications using protected data carriers, particu- 
larly In the case where smart cards or smart card read- 
ers cannot be used. The improved communication 
architecture has a common virtual smart card interface 
between the respective smart card applications and the 
modules which facilitate access to the protected data 
carriers (smart cards). The modules allow access to 
either physical smart cards, virtual software smart cards 
or hardware smart cards. The common virtual smart 
card interface means that the application is completely 
independent of the respective module or the respective 
data carrier. Alternatively, the Improved communication 
architecture additionally contains a virtual smart card 
adapter which communicates over the cornmon virtual 
smart card interface with the respective smart card 
application. The different modules are attached to the 
smart card adapters and selected statically or dynami- 
cally over the smart card application. Virtual software 
smart cards which functionally imitate true physical 
smart cards can be linked over the virtual smart card 
adapter to communicate with a smart card application. 
This procedure is then particularly suited for when the 
smart card is lost or defective, the smart card reader 
cannot function, or for testing new smart card technolo- 
gies. 
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Description 

[0001] The present invention describes an expanded 
snfiart card architecture lor communicating between the 
smart card application and a data carrier, particularly in 5 
the case where the smart card or the smart card reader, 
for whatever reason, is not present or cannot be used. 
[0002] With the introduction of new technology and 
programs which necessitate the use of smart cards, the 
problem of short term availat)ility of smart card readers io 
often arises. Workstations for users must be converted 
to new smart card readers which conform to this tech- 
nology. This is often very laborious from a technical 
point of view and, particularly in large companies, takes 
a great deal of time. The result of this is that new tech- is 
nologies or programs have to be operated together with 
old technologies and programs in a transitional phase. 
This is both cost and labour intensive. . 
[0003] Defective smart card readers prevent transac- 
tions using the smart card. This can be economically 20 
disadvantageous both for the smart card owner as well 
as for the operator of the smart card reader, depending 
on the field of use. 

[0004] In the case of a smart card being lost, the 
owner is prevented from working with the smart card 25 
until a new card is issued. In certain cases, e.g. during 
long trips away, this can lead to problems for the owner. 
This is increasingly the case because many business 
activities are extensively carried out using smart cards. 
[0005] It is therefore the task of the present invention 30 
to produce a procedure and system which is able to 
avoid the above mentioned disadvantages. 
[0006] The task is solved by the features of claims 1 , 
20 and 30. Additional advantageous embodiments are 
presented in the sul>claims. 3S 
[0007] The advantages of the present invention are 
that a virtual software smart card can be used instead of 
a physical smart card. The virtual software smart card 
represents a pure software solution and is modelled on 
the functions of a physical smart card. The testing of 40 
new smart card solutions is limited to the testing of the 
virtual software smart card. The creation of a virtual 
software smart card, based on a new smart card solu- 
tion, is less time consuming and thus also cheaper than 
creating a smart card. Laborious smart card prototypes 45 
for testing the newly developed smart cards thus 
become unnecessary In the case of loss of the physical 
smart card, the person entitled to do so can download a 
virtual software smart card using a diskette or over the 
Net into his system and continue to work using this vir- so 
tual software smart card until a new smart card is 
issued. 

[0008] Organisations and companies can use new 
smart card technology by making available virtual soft- 
ware smart cards, without all the systems having to be ss 
equipped already with new smart card readers. For 
smart card manufacturers, the advantage is that new 
technologies can be tested in the later application envi- 



ronment before components (such as crypto-coproces- 
sors, large memories, etc.) are availak)ie. 
[0009] By introducing a common virtual smart card 
interlace and a virtual smart card adapter, communica- 
tion between the smart card application and the mod- 
ules of the virtual smart card adapter is completely 
independent. For the smart card application, it makes 
no difference with which module of the virtual smart 
card adapter it is communicating. Modules are access 
routines on a physical smart card, a virtual software 
smart card or a hardware smart card with the function- 
ality of a smart card. Changes and amendments in tiie 
modules or ttie virtual smart card adapter do not require 
any adaptation of the respective smart card application 
due to the comnron virtual smart card interface. 
[001 0] The present invention will be explained in more 
detail using a preferred embodiment exanple and fig- 
ures where: 

Rg. 1 shows a communication architecture 
between smart card applications and smart cards 
or smart card modules 

Rg. 2 shows the communication architecture in 
accordance with the invention between different 
smart card applications and different data earners. 

[001 1] Fig. 1 describes a communication architecture 
between different smart card applications and different 
smart cards. The identification of the card is canried out 
by the application. The different applications communi- 
cate with specific smart card access routines over spe- 
cial interfaces (PKCS#11. CDSA, CAPI). The respective 
smart card access routines are either a part of tiie 
respective application or form a separate software com- 
ponent. For different smart cards with different operat- 
ing systems or different data structures, they have their 
own access routines. Each new smart card or changes 
to the operating system software or data structijre of a 
smart card requires an adaptation of the respective 
access functions. 

[0012] Fig. 2 describes the communication architec- 
ture in accordance with the invention between different 
smart card applications and different data carriers. Dif- 
ferent applications communicate over a common virtual 
smart card interface (VCS) witii tiie respective modules. 
Applications 1 and 2, for example, touch on a standard- 
ized interface such as PKCS #11 and application 3 
touches on a standardized interface such as CAPI. The 
implementation of different standard interfaces (PKCS 
#11. CDSA. CAPI) uses the common virtual smart card 
interface. Application 4 touches directly on the common 
virtual smart card interface. Preferably, a virtual smart 
card adapter (VCS adapter) Is anranged below tiie com- 
mon virtual interface. 

[0013] The VCS adapter Is a software module and 
offers a uniform interface for all applications. Different 
modules (smart card modules, software smart card 
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modules, hardware card modules) can be attached to 
the VCS adapter. The applications can Interrogate the 
accessible modules over the VCS adapter. The applica- 
tion can communicate with a selected module over the 
VCS adapter. The selection of the respective nrKXiule 
can be carried out statically or dynamically. In the case 
of dynamic linking of a module, over the Net for exam- 
ple, the VCS adapter checks the identity and authentic- 
ity of the module, i.e. whether the module has been 
created by an authorized entity and has not been modi- 
fied in the meantime. The module receives a digital sig- 
nature which is tested by the VCS adapter on creating 
the communication. The VCS, too, can also be con- 
nected statically or dynamically to the application. In tiie 
case of dynamic connections, the smart card applica- 
tion checks the Identity and authenticity of tiie VCS 
adapter. Therefore, even the application can be linked 
dynamically to the VCS adapter over the Net. 
[0014] Also, in this case the identity and autiienticity 
of smart card applications must be checked. The check 
here on authenticity is also carried out using a digital 
signature. 

[0015] Alternatively, tiie smart card application, the 
VCS adapter and also tiie modules attached to it can be 
linked statk^ally. In this case, a digital signature is 
unnecessary. 

[0016] Modules are the access routines to the data 
objects; tiie data objects can, for example, be stored in 
a physical or a virtual smart card or on a hardware 
smart card. Cryptographic functions are filed either in 
the module or on a physical smart card or a hardware 
smart card (e.g. PCM/CIA card) . In tiie case of a virtual 
software smart card, the cryptographic functions are a 
part of the virtual software smart card. 
[001 7] Access to private data on a physical smart card 
or hardware smart card is protected by a password (e.g. 
PIN). 

[0018] With the virtual software smart cards, private 
data is additionally encoded witii the support of the 
password. The codes of tine virtual software smart cards 
are additionally protected, particularly against being 
read out. 

[0019] Several standardized virtual software smart 
card types can be developed and stored on a storage 
medium; the virtual software smart cards can also be 
distributed over the Internet to users. Virtual software 
smart cards have a generic structure and do not contain 
any user-specific data. They simply represent the 
method of functioning of a physical smart card. There- 
fore, tiiey need to be initialized/personalized by the user. 
The initialization of the virtual software smart card pref- 
erably precedes an authentication procedure which 
establishes whether changes have been made in the 
virtual software smart card in the transmission of the vir- 
tual software smart card from one system to the other. 
The virtual software smart card is preferably equipped 
with a user internee for initializing the virtual smart 
card. The user interface asks the user, for example. 



which virtual software smart card type is required. 
Smart card types cover, for example, signature cards, 
access cards or data cards. The user interface asks the 
user to determine a password or to accept or change an 

5 existing password. The virtual software smart card gen- 
erates a code from the password. From the information 
requested, a memory area is established on the hard 
disk of tiie user for storing public data objects and a 
memory area for storing private data objects. This is 

10 carried out by functions of the virtual software smart 
card. Components of the virtual software smart card are 
tiie access routines on the data objects which are 
stored on the hard disk. The public data objects are 
freely accessible; private data objects can only be 

75 accessed using a code/|Dassword. The user is able to 
work using the virtual software smart card. 
[0020] The VCS adapter can be a component of tiie 
virtual smart card or can represent its own software 
component which is nriade available together witii tiie 

20 virtual software smart card. 

Claims 

1. Communication architecture for tiie exchange of 
25 information between a smart card application and a 

protected data cannier containing at least the follow- 
ing components: 

a) a smart card application 

30 

b) a virtual smart card adapter with a common 
interface to all smart card applications for link- 
ing in modules for access to protected data car- 
riers 

35 

c) a rTKxIule with access routines to a protected 
data carrier 

d) a data carrier witii private and public data 
40 objects where the private data can be pro- 
tected against access. 

2. Communication architecture in accordance with 
claim 1 , characterised in that tine module is able to 

45 be connected statically to the smart card adapter. 

3. Communication architecture in accordance witii 
claim 1 , characterised in that the module is able to 
be connected dynamically to tiie smart card 

50 adapter. 

4. Communication architecture in accordance with 
claim 3, characterised in that the module is able to 
be connected dynamically with the smart card 

55 adapter over tiie Net. 

5. Communication architecture in accordance with 
claims 3 or 4. characterised in that tiie module 
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which can be selected dynamically is able to have 
its identity and/or authenticity checked by the smart 
card adapter. 

6. Communication architecture in accordance with 
claims 3 to 5, characterised in that the authenticity 
of the module Is able to be checked by a digital sig- 
nature. 

7. Communication architecture in accordance with 
claims 1 to 6, characterised in that the smart card 
adapter is able to be connected statically with the 
smart card application. 

8. Communication-architecture in accordance with 
claims 1 to 6. characterised in that the smart card 
adapter is able to be connected dynamically to the 
smart card application. 

9. Communication architecture in accordance with 
claim 8, characterised in that the smart card 
adapter is able to be connected dynamically over 
the Net to the smart card application. 

10. Communication architecture in accordance with 
claims 8 and 9, charactersied in that the smart card 
adapter which can be connected dynamically is 
- able to have its identity and/or authenticity checked 
by the smart card application. 

11. Communication architecture in accordance with 
claims 8 to 10, characterised in that the authenticity 
of the smart card adapter is able to be checked 
using a digital signature. 

12. Communication architecture in accordance with 
claims 1 to 1 1 , characterised in that the modules, 
which are able to be connected to the smart card 
adapter over the smart card application program, 
are able to be Interrogated, selected and con- 
nected. 

13. Communication architecture in accordance with 
claims 1 to 12. characterised in that the protected 
data carrier is a physical smart card, a virtual soft- 
ware smart card or a hardware smart card with the 
functionality of a smart card. 

14. Communication architecture in accordance with 
claims 1 to 13, characterised in that the virtual soft- 
ware smart card is able to be connected dynami- 
cally or statically to the respective nrKxlule. 

15. Communication architecture in accordance with 
claims 1 to 14. characterised in tiiat the identity 
and/or authenticity of the virtual software smart 
card is able to be checked by the module. 



16. Communication architecture in accordance with 
daims 14 to 15, characterised in tiiat the test of 
authenticity of the virtual software smart card which 
can be connected dynamically is carried out using a 

5 digital signature. 

17. Communication architecture in accordance with 
claims 1 to 16, characterised in that the virtual soft- 
ware smart card is able to be initialized and person- 

10 alized. 

18- Communication architecture in accordance with 
claims 1 to 17. characterised in tiiat data objects 
are able to be filed on the data carrier through tune- 
rs tions of the virtual software smart card and access 
to the data objects by the module are able to be cre- 
ated using functions of the virtual smart card. 

19. Communication architecture in accordance witii 
20 claims 1 to 18, characterised in that cryptographic 

functions for coding and encoding data are part of 
tiie virtual software smart card. 

20. Communication architecture for tiie exchange of 
25 information between a smart card application and a 

protected data can-ier containing at least ttie follow- 
ing components: 

a) a smart card application 

30 

b) a module with access routines to a protected 
data carrier 

c) a virtual software smart card with crypto- 
35 graphic functions for filing, reading and writing 

data objects on a data carrier 

d) a data carrier on which data objects with pri- 
vate and public data can be stored, whereby 

40 private data can be protected against access 

using the virtual software smart card. 

21. Communication architecture in accordance with 
claim 20, characterised in that the module is able to 

45 be connected statically or dynamically to ttie smart 
card application. 

22. Communication architecture in accordance with 
claim 21, characterised in that in the case of 

50 dynamic connection of the module with tiie smart 
card application, its identity and/or authenticity is 
able to be checked using a digital signature. 

23. Communication architecture in accordance with 
55 claims 20 to 21, characterised in that tiie virtual 

software smart card is able to be connected stati- 
cally or dynamically to the module. 
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24. Communication architecture In accordance with 
claim 23. characterised In that in the case of 
dynamic connection of the virtual software smart 
card to the nrxxiule. Its Identity and/or authenticity Is 
able to be checked using a digital signature. s 

25. Communication architecture In accordance with 
claims 20 to 24. characterised in that a virtual smart 
card adapter with an interface common to all smart 
card applications for linking modules for access to io 
protected data carriers is additionally able to inte- 
grated. 

26. Communication architecture in accordance with 
claim 25, characterised in that the smart card 75 
adapter is able to be connected dynamically to the 
smart card application. 

27. Communication architecture In accordance with 
claim 26, characterised in that the smart card 20 
adapter is able to be connected dynamically over 
the Net to the smart card application. 

28. Communication architecture in accordance with 
claims 25 and 26. characterised in that the smart 25 
card adapter which can be connected dynamically 

is able to have Its Identity and/or authenticity 
checked by the smart card application. 

29. Communication architecture In accordance with 30 
claims 25 to 28, characterised in that the modules 
which can be connected to the smart card adapters 
are able to be inten^ogated, selected and connected 
over the smart card application program. 

35 

30. Procedure for implementing virtual software smart 
cards where the software smart cards functionally 
imitate physical smart cards, characterised by the 
following steps: 

40 

a) the offering of a user-interface for the selec- 
tion of types of virtual software smart cards 
which are filed on a storage medium 

b) the selection of a virtual software smart card 45 
in accordance with step a) by the user 

c) the personalizing of the virtual software 
smart card by the user entering a password 

so 

d) the generation of private and public data 
objects on a storage medium using software 
smart card functions 

e) the availability of access functions to the 55 
data objects using software smart card func- 
tions where private data objects are protected 
from unauthorized access. 
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